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TELNET STATUS OPTION 

This RFC specifies a standard for the ARPA Internet community. Hosts on 
the ARPA Internet are expected to adopt and implement this standard. 
1. Command Name and Code 

STATUS 5 
2. Command Meanings 

This option applies separately to each direction of data flow. 

IAC DON’T STATUS 


Sender refuses to carry on any further discussion of the current 
status of options. 


IAC WON’T STATUS 


Sender refuses to carry on any further discussion of the current 
status of options. 


IAC SB STATUS SEND IAC SE 
Sender requests receiver to transmit his (the receiver’s) 
perception of the current status of Telnet options. The code for 
SEND is 1. (See below.) 


IAC SB STATUS IS ... IAC SE 


Sender is stating his perception of the current status of Telnet 
options. The code for IS is 0. (See below.) 


3. Default 
DON’T STATUS, WON’T STATUS 
The current status of options will not be discussed. 
4. Motivation for the Option 
This option allows a user/process to verify the current status of 


TELNET options (e.g., echoing) as viewed by the person/process on the 
other end of the TELNET connection. Simply renegotiating options 
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could lead to the nonterminating request loop problem discussed in 
the General Consideration section of the TELNET Specification. This 
option fits into the normal structure of TELNET options by deferring 
the actual transfer of status information to the SB command. 


5. Description of the Option 
WILL and DO are used only to obtain and grant permission for future 


discussion. The actual exchange of status information occurs within 
option subcommands (IAC SB STATUS...). 


Once the two hosts have exchanged a WILL and a DO, the sender of the 
WILL STATUS is free to transmit status information, spontaneously or 
in response to a request from the sender of the DO. At worst, this 
may lead to transmitting the information twice. Only the sender of 
the DO may send requests (IAC SB STATUS SEND IAC SE) and only the 
sender of the WILL may transmit actual status information (within an 
IAC SB STATUS IS ... IAC SE command). 


IS has the subcommands WILL, DO and SB. They are used EXACTLY as used 
during the actual negotiation of TELNET options, except that SB is 
terminated with SE, rather than IAC SE. Transmission of SE, as a 
regular data byte, is accomplished by doubling the byte (SE SE). 
Options that are not explicitly described are assumed to be in their 
default states. A single IAC SB STATUS IS ... IAC SE describes the 
condition of ALL options. 
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The following is an example of use of the option: 
Host1l: IAC DO STATUS 
Host2: IAC WILL STATUS 
(Host2 is now free to send status information at any time. 
Solicitations from Hostl are NOT necessary. This should not 
produce any dangerous race conditions. At worst, two IS’s will 
be sent.) 


Hostl (perhaps): IAC SB STATUS SEND IAC SE 


Host2 (the following stream is broken into multiple lines only for 
readability. No carriage returns are implied.): 


IAC SB STATUS IS 

WILL ECHO 

DO SUPPRESS-GO-AHEAD 

WILL STATUS 

DO STATUS 

IAC SE 
Explanation of Host2’s perceptions: It is responsible for echoing 
back the data characters it receives over the TELNET connection; 


it will not send Go-Ahead signals; it will both issue and request 
Status information. 
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